Skip to main content

07 - 平台选型与落地

前置：02 到 06 篇。本篇是收口。

本篇回答：这些东西凑一起该买谁、装谁、按什么顺序上。

本篇会用到的词：

词意思
ELv2Elastic License 2.0。允许自用和改，但禁止把它作为托管服务卖给第三方。不是 OSI 认定的开源许可
open-core核心开源、企业功能闭源的模式。典型标志是仓库里有个 ee/ 目录，单独一份许可证
NOASSERTIONgh api 返回的许可证字段值，意思是「自动识别不出来」，不等于没有协议。看到它必须自己去翻 LICENSE
评测（eval）给模型输出打分。可以是规则、可以是另一个模型当裁判。它和追踪的关系是：追踪提供被打分的样本

一、先分清三类产品​

选型最常见的混乱，是把不在同一层的东西放在一张表里比：

第一类和后两类是「组合」关系，后两类之间才是「二选一」关系① 埋点库OpenInference · OpenLLMetryopentelemetry-python-genai · OBI只产数据，发往任意 OTLP 端OTLP② LLM 专用平台Langfuse · Phoenix · Opik · MLflowtrace 查看 ＋ 评测 ＋ 成本看板强项：提示词管理、数据集、打分③ 通用可观测栈SigNoz · ClickStack · Grafana 栈GenAI 数据与基础设施指标同库强项：和 CPU、DB、K8s 事件关联②和③的分界在于「你排查时最想关联的是什么」：想关联「上一版提示词长什么样」选②，想关联「那会儿 GPU 是不是被别的任务占满了」选③。常见的实际形态是两个都有：③接全量做基础设施视角，②接重点服务做 AI 视角，靠同一份 trace ID 串起来。把①和②放在一张表里比是没有意义的 —— OpenLLMetry 替代的不是 Langfuse，而是你自己手写的那些埋点代码。
这张分层图也解释了为什么本专题把埋点放在第 02 篇、平台放在最后一篇：埋点是最难改的决定，平台是最容易换的。

二、五个开源平台横评​

数据日期 2026-08-21，许可证一栏是逐个打开仓库 LICENSE 文件读的，不是 gh api 的自动识别结果：

项目★许可证（实读）自建依赖语义约定侧重
langfuse/langfuse33,466核心 MIT Expat；ee/、web/src/ee/、worker/src/ee/ 另有商业许可。版权持有人已变更为 ClickHouse, Inc.ClickHouse ≥ 24.3 ＋ Postgres ＋ Redis ＋ 对象存储自有模型，两套约定都映射进来全功能工程平台：追踪、评测、提示词管理、数据集
Arize-ai/phoenix11,128Elastic License 2.0 —— 非 OSI 开源，禁止作为托管服务转售SQLite 起步；生产建议 PostgreSQL ≥ 14OpenInference 原生本地调试与评测，起步最轻
comet-ml/opik21,500Apache-2.0（整仓）MySQL ＋ Redis ＋ ClickHouse ＋ ZooKeeper ＋ MinIOOTel 兼容追踪 ＋ 评测 ＋ 内置护栏服务
SigNoz/signoz31,890核心 MIT Expat；ee/、cmd/enterprise/ 另有商业许可ClickHouseOTel 原生通用可观测栈，GenAI 是其中一块
mlflow/mlflow27,594Apache-2.0可从文件后端起步原生支持 GenAI 语义约定已有 MLflow 的团队顺手接上

外加一个不在同一层的：

项目★许可证说明
traceloop/openllmetry7,387Apache-2.0只做埋点，不含后端。 它替代的是你手写的埋点代码，不是上面任何一个

2.1 许可证这一栏必须自己翻​

gh api 对 Langfuse、Phoenix、SigNoz 返回的都是 NOASSERTION。翻完之后结论差异很大：

项目自动识别实际情况对采购的影响
LangfuseNOASSERTION核心 MIT，ee/ 商业许可自用没问题；要注意别不小心依赖了 ee/ 里的功能
SigNozNOASSERTION核心 MIT，ee/ 商业许可同上
PhoenixNOASSERTIONELv2自用可以；做成对外服务卖给第三方不行。做 PaaS 的团队要特别注意

Phoenix 那一行是三者里唯一有实质限制的。"开源"这个词在这里不成立 —— ELv2 不是 OSI 认定的开源许可，企业法务过审时按商业软件处理。

Opik 和 MLflow 是整仓 Apache-2.0，没有这层麻烦。

2.2 部署重量差得比想象中大​

"装个 Langfuse 试试"和"装个 Phoenix 试试"是完全不同的两件事：

横条长度＝要维护的中间件套数。这是「先跑起来」和「长期运维」的真实成本差Phoenix1 套 · SQLite，生产建议换 PostgreSQL最轻MLflow1 套 · 可从文件后端起步最轻SigNoz1 套 · ClickHouse中Langfuse4 套 · ClickHouse ＋ Postgres ＋ Redis ＋ 对象存储重Opik5 套 · MySQL ＋ Redis ＋ ClickHouse ＋ ZooKeeper ＋ MinIO最重套数读自各项目官方的 docker-compose.yaml 与自建文档，不含平台自身的应用容器。
重不等于差 —— Langfuse 那四套正是 05 篇第五节那条摄入路径的物理形态，它换来的是流量尖峰下不丢数据。问题只在于：这笔运维成本得有人付。

评估自建时按中间件套数算人力，不要按"一个应用"算。 五套中间件意味着五套备份策略、五套监控、五个版本升级窗口。

三、怎么判断"生产上真的有人在用"​

star 数不行 —— 04 篇已经说过规范类仓库的 star 没有意义，平台类仓库也一样会被"看起来很酷"的项目刷高。四个更可靠的信号：

信号怎么查例子
有没有别的基础设施项目在生产路径上依赖它读对方源码，不是读对方的 READMEEnvoy AI Gateway 的 internal/tracing/openinference/ 是完整实现，不是可选插件
有没有被 OTel 官方吸纳看 contrib 仓库里有没有对应组件genainormalizerprocessor 内置了 openinference 和 openllmetry 两张映射表 —— 官方认为这两个值得专门支持
有没有资本层面的确认收购、融资公告里的量化口径ClickHouse 于 2026-01-16 收购 Langfuse，公布数字：SDK 月安装 26M+、Docker 拉取 6M+、Fortune 500 里 63 家在用
架构能不能扛住量读它的自建文档，看有没有队列和冷热分离Langfuse 的 S3 缓冲 ＋ Redis 引用队列是为尖峰设计的；Phoenix 的 SQLite 起步显然不是

第四条最实用，因为它是你自己能验证的。一个平台如果让 SDK 直连数据库、没有中间队列，它在流量尖峰下一定会以超时的形式丢数据 —— 这与它的 star 数无关。

3.1 一个可以直接问供应商的问题​

不管开源还是商业，有个问题能快速分辨"真在生产跑过"和"demo 做得好"：

我们用了持久化执行框架，故障恢复时工作流会从头重放，同一个步骤在 trace 里会出现两次。你们怎么处理？

答得上来说明对方见过真实的 Agent 生产系统。这个问题在 Agent 持久化执行 · 05 篇也提到过，两边是同一个判据。

同类的还有：

  • 一次执行跑了 40 分钟，你们的尾采样怎么办？（对应 05 篇 3.1 节）
  • 我们不想让 prompt 落到你们的库里，有没有只存引用的模式？（对应 04 篇 5.2 节）
  • 一次对话 60 轮，你们的 span 属性会不会被截断？（对应 04 篇 3.1 节）

四、按场景选​

你的情况选什么
本地开发，想先看看 trace 长什么样Phoenix。 pip install 或 docker run 就能起，OpenInference 原生。但注意 ELv2
要成本看板、多租户、提示词管理，且有人力运维Langfuse。 功能最全，被 Fortune 500 里 63 家用着；代价是四套中间件
已经有一整套 OTel ＋ ClickHouse 可观测栈SigNoz 或 ClickStack。 别再单独立一套 LLM 平台，让 GenAI 数据和基础设施数据同库
团队本来就在用 MLflow 管模型MLflow Tracing。 生产用轻量的 mlflow-tracing 包，它比全量 MLflow 小 95%
法务对许可证有硬要求Opik 或 MLflow，整仓 Apache-2.0。Phoenix 的 ELv2 过不了"必须是 OSI 开源"这条
做 PaaS，要把可观测能力转售给客户不能用 Phoenix（ELv2 明确禁止）。Langfuse / SigNoz 要避开 ee/
只缺埋点，后端已经有了OpenLLMetry 或 OpenInference，它们不是后端
多语言混合、要防绕过、要做全公司盘点OBI（03 篇）＋ 网关侧采集（06 篇）

五、落地顺序​

按依赖关系，四步走。顺序不能颠倒 —— 后一步的价值建立在前一步已经做完的前提上：

每一格下面那行红字，是跳过这一步之后会在几个月后付出的代价① 让数据产生选一个埋点库装上网关侧同时打开记账先不记 prompt 内容跳过 → 后面全是空谈② 立管道Collector 两层拓扑归一 ＋ 脱敏白名单span metrics 排在采样前跳过 → 换后端时数据带不走③ 接后端按第四节选一个配尾采样策略决定内容记不记、记哪档跳过 → 存储成本失控④ 闭环成本报表走指标线上样本回流做评测异常步数上告警这一步才产生业务价值②之所以排在③前面，是因为归一和脱敏的位置一旦定错，纠正它要重新处理已落库的历史数据 —— 而后端本身是随时可换的。①里「先不记 prompt」是有意的：默认档位跑一个月，看清数据量和查询模式之后，再决定要不要开、开哪一档、存哪里。最常见的翻车顺序是先上④——老板要成本看板，于是直接查 trace 库求和，采样一开数字就全错了。
四步大致对应本专题的 02、04+05、05+07、06 篇。如果只能做两步，做①和②——它们决定了以后还能不能补做③④。

六、全专题结论​

  1. 埋点混用，不要二选一。 B/C 拿框架内部结构，D 拿不可伪造的账，A 补业务维度。四项独占能力分散在谱系的两端和中段，没有任何单一路线能覆盖全部。（02、03）
  2. 规范未稳定，把归一做在 Collector 里。 118 个 gen_ai.* 属性全是 development，genainormalizerprocessor 是唯一能对历史数据也生效、改错了不用发版的位置。（04）
  3. 内容默认不记，要记就外置。 prompt 记不记差 13 倍存储；记在 span 属性上还会和尾采样的内存直接冲突。（04、05）
  4. 采样策略要按 Agent 的特征配。 出错的、慢的、步数异常的、token 超量的必留 —— 后两条传统 APM 里没有对应概念。（05）
  5. 成本口径放网关，报表走指标。 应用侧传入的身份可被伪造；trace 经采样后求和必然失真。（06）
  6. 观测数据本身需要治理。 脱敏、访问控制、保留期，三项都不能用默认值 —— trace 库的权限模型通常比业务数据库松得多。（04）

← 回到 专题索引 　·　 Agent Infra 板块总览